Subject: RFC1593 - SNA APPN Node MIB

From: [email-masked]
Date: Tue, 22 Mar 94 15:40:39 EST

Dear AIW participants:

In case you have not got this, the APPNMIB implemented in IBM's
APPN OEM code package has become an informational RFC, RFC1593.
Now for vendors who licensed IBM's APPN code, you have an RFC
number to use when referencing the APPN MIB.
For other vendors, there is an APPNMIB RFC which is readily available
for you to implement.

In an effort to decide how much IBM should do to expand the support
of RFC1593,  the AIW organizing committee and the SNASNMP working group
would like to make a poll:

Please speak up, send a message to this mailing list, if your company
has an interest, or has a short/long term plan to support RFC1593
(either in full or in part) in your products.

This is important because it affects IBM's decision on continuous effort
toward a standardized APPN MIB, which in turn makes your APPN products
more manageable.

The polling period starts now until March, 31, 1994.
Don't miss out the opportunity to voice your opinion!

Best Regards,

Robin Cheng,  [email-masked]
Mike Allen, [email-masked]
IBM Networking Systems Architecture

---

From: [email-masked]
Date: Thu, 24 Mar 94 06:56:31 PST

>Don't miss out the opportunity to voice your opinion!

Robin -

    Me miss an opportunity to voice my opinion!?  Never! :-)

    Without going into a lot of analysis of the various MIB objects, I see
    the following problems:

	(1) At the highest level, this is hardly a generic APPN MIB.  As a
	    cisco engineer, I have a difficult time having to present our
	    router as an IBM 6611 in order to be managed :-).

	    I've appended the relevant SMI below.

		IBM-6611-APPN-MIB DEFINITIONS ::= BEGIN

		IMPORTS

		    [ *** deleted *** ]

		ibm             OBJECT IDENTIFIER ::= { enterprises 2 }
		ibmProd         OBJECT IDENTIFIER ::= { ibm 6 }
		ibm6611         OBJECT IDENTIFIER ::= { ibmProd 2 }
		ibmappn         OBJECT IDENTIFIER ::= { ibm6611 13 }

		    [ *** remainder deleted *** ]

	(2) There is considerable overlap between the APPN MIB and both
	    the SNA NAU and the SNA DLC MIBs.  Primary regions of conflict
	    are:
		APPN MIB		Conflicts with
		--------		--------------
		ibmappnNode 	 	snaNodeAdminTable of SNA NAU MIB
		ibmappnNodePortTable	sdlcPortAdminTable and
					sdlcPortOperTable of SNA DLC MIB
					(LLC MIB in progress)
		ibmappnNodeLsTable	sdlcLSAdminTable and
					sdlcLSOperTable and sdlcLSStatsTable
					of SNA DLC MIB
					(LLC MIB in progress)

	    All of the APPN-specific objects (such as those relating to
	    TGs, topology, directory, etc.) are fine.

	(3) There is only a single read-write object in the entire MIB.
	    I realize there is a design conflict between NOF and SNMP
	    here, but the industry is moving in the direction of
	    allowing SNMP management stations to control the active
	    network devices.  This MIB doesn't provide the framework
	    to migrate toward the SNMP Set based control of an APPN
	    node.

    One last general comment.  The information accessible in the APPN MIB
    should remain parallel with the information that is available from the
    SNA/MS-based implementations on OS/400 and OS/2.  Otherwise, the "open"
    APPN community will lag behind the IBM-internal implementations of
    APPN in terms of manageability.

    I will be at the IETF in Seattle next week and will discuss these
    issues with Mike Allen (I didn't see your name on the IETF attendee
    list this time).

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627